home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941221-19950208 / 000011_news@columbia.edu_Fri Dec 23 15:59:54 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA14446
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 23 Dec 1994 11:00:01 -0500
  3. Received: by apakabar.cc.columbia.edu id AA17092
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 23 Dec 1994 10:59:57 -0500
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: HANGUP problem on FreeBSD
  9. Date: 23 Dec 1994 15:59:54 GMT
  10. Organization: Columbia University
  11. Lines: 72
  12. Message-Id: <3des5q$gm2@apakabar.cc.columbia.edu>
  13. References: <3ddrrl$hc@cruella.ee.pdx.edu>
  14. Nntp-Posting-Host: watsun.cc.columbia.edu
  15. Keywords: HANGUP timing FreeBSD DTR
  16. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  17.  
  18. In article <3ddrrl$hc@cruella.ee.pdx.edu>,
  19. Roland Kwee <rkwee@ee.pdx.edu> wrote:
  20. >Issuing the HANGUP command on my FreeBSD system drops the
  21. >DTR line forever, instead of just 0.5 second, as explained
  22. >in the C-Kermit book (page 45). I use the modem setting 'direct'.
  23. >
  24. >On my Linux system, the command works according to the book.
  25. >It is a problem for me, because I try to connect both systems
  26. >with a direct line and SLIP, and the HANGUP command should
  27. >cause the other machine to logout. However, I found no way
  28. >to get the DTR on the FreeBSD box back to ON! (except SET LINE).
  29. >
  30. >Can anyone tell me if this is supposed to depend on the OS?
  31. >If it may be a bug? How to turn DTR to ON?
  32. >
  33. It is supposed to work as described in the book.
  34.  
  35. During (and after) the development of C-Kermit 5A(190), FreeBSD kept
  36. changing out from under me.  I received numerous "patches" from all over
  37. the world, most of them mutually contradictory.
  38.  
  39. As you have probably seen by inspecting the tthang() routine in ckutio.c,
  40. the simple act of dropping DTR for half a second is one of the hardest
  41. things to do in non-vendor-specific UNIX communications software, since
  42. there are so many different ways to do it -- each system has its own way.
  43. tthang() presently takes up 405 lines of code, and still fails to work in
  44. some cases, like yours.
  45.  
  46. The POSIX method is used In the FreeBSD case -- relatively straightforward
  47. (get current speed, save it, set speed to 0, sleep half a second(*),
  48. restore speed), so if it doesn't work, there is probably something wrong
  49. underneath -- i.e. in FreeBSD or your serial port driver.
  50.  
  51. All I can say is, you are free to make changes to tthang() and send them
  52. to me, but don't have any confidence that your changes will work for any
  53. length of time, given FreeBSD's track record on stability so far (speaking
  54. as an outsider, no offense intended).  I don't have access to any FreeBSD
  55. systems to do this work myself.  Also, in my correspondence with other
  56. FreeBSD users, nobody has reported a problem like this, so it's very
  57. likely peculiar to a specific configuration (kernel edit, driver edit,
  58. whatever).
  59.  
  60. >In general, is there a way with Kermit to set ANY of the handshake lines
  61. >to arbitrary values? Would be neat for testing all kinds of things.
  62. >
  63. This would be a great feature, but no, there is no standard or portable
  64. way (not even several standard ways) to set arbitrary modem signals.
  65. C-Kermit does have a "show modem" command, which works on the (few) UNIX
  66. variations that allow modem signals to be tested.  HP-UX probably has the
  67. best serial i/o interface I've seen; very few others even approach it.
  68.  
  69. UNIX "standards bodies" have vigorously avoided the area of serial
  70. communications, which, even in this age of low-cost, high-speed modems and
  71. the worldwide public stampede to the "on-ramp" of the "information
  72. superhighway" -- a time when serial communications is becoming more
  73. important than ever before.
  74.  
  75. POSIX made some progress, but it's only one of many APIs, and even the
  76. POSIX.1 API is inadequate.  It does not address questions of exclusive
  77. access (which leaves us, still, with the "UUCP lockfile" -- one of the
  78. most atrocious ideas in software engineering ever to gain "de facto
  79. standard" status, ranking right up there with cooperative multitasking,
  80. with which it has more than a little in common), hardware flow control,
  81. modem signals, nondestructive input-buffer peeking, or fine-grained (under
  82. one second) sleeps, all of which are essential for serial communications.
  83.  
  84. (*) But since there is no way to sleep for half a second in POSIX,
  85.     we have to use some kind of non-POSIX-compliant method, i.e.
  86.     an "extension", and this might be a good place to start
  87.     looking for the problem.  See the msleep() routine in ckutio.c.
  88.  
  89. - Frank